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A Claim Data and Document Processing System 

The present Utility patent application is based on Provisional patent application 
no. 60/457,197, filed on March 25, 2003. 

FIELD OF THE INVENTION 

The present invention relates generally to the field of financial data processing, 
and more particularly to systems that facilitate the identification and processing of 
reimbursement claim data, including documentation supporting such claims. 

BACKGROUND OF THE INVENTION 

Many businesses provide services to customers in which reimbursement of at 
least a portion of the fee for the provision of those services is expected to be paid by a 
third party. For example, automobile repair businesses provide repair services for the 
owners of automobiles. In the case of an accident, reimbursement of at least a portion 
of the fee for those repairs may be made by an automobile insurance company. 
Similarly, repairs provided by home repair companies may under some circumstances 
be reimbursed by the homeowner's insurance company. 

To receive reimbursement from the third party, such businesses submit a claim 
to the third party. Each such third party requires that certain data, which may include 
supporting documentation, be provided to them in that claim before they will provide the 
reimbursement to the businesses. If all required claim data is provided, then the 
reimbursement will be provided to the business. However, is any required claim data is 
missing, then the third party will not provide reimbursement until the missing data is 
submitted to them. 

This is also generally true for provision of medical services to patients. Most 
patients at doctors' offices, hospitals, dental offices or other healthcare providers have 
medical insurance or are the beneficiary of some form of some other third party (e.g. 
employer) reimbursement. The healthcare provider, in order to obtain payment for 
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medical services rendered to a patient, assembles the data required by the third party 
(termed a payer) to generate a claim for reimbursement. This claim is sent to the third 
party payer. The payer evaluates the data in the claim and returns the payment to the 
healthcare provider for the rendered service. Approximately twenty percent of claims 
5 for reimbursement submitted by healthcare providers require some sort of attachment, 
such as a photocopy of an invoice, a lab report or an x-ray or photograph, be sent to the 
payer in order to complete the claim. 

Prior claim filing systems have attempted to address the problem of tracking and 
retrieving necessary attachments by means of entirely manual processes. In these 
known systems, a clerk analyzes the reimbursement claim to determine which, if any, 
attachments are required. The clerk then retrieves the required attachments, which 
may reside in hardcopy form, from various file cabinets possibly at several different 
locations. Such manual systems require that a copy be made and sent, often by mail, 
to the payer as part of the completed claim request. A manual system requires 
substantial record keeping. In addition, in the case of healthcare services, information 
from different entities appears on different forms and is not formatted for ready access 
by others. In these cases the attachment are manually generated. 

Some automated systems define sets of rules executable by software-based 
rules engines that prompt or query a system user concerning the need for an 
20 attachment. However, such systems only indicate the need for an attachment and do 
not specify the particular type of attachment that is needed or identify the specific 
document to be retrieved. For example, such a system may indicate that an emergency 
room report is required as an attachment. But the patient in question may have had 
several emergency room admissions. The user determines which specific desired 
25 emergency room report is required. This requires time and effort by the healthcare 
provider's personnel in order to identify and retrieve the necessary attachment. 

Other related data processing systems link insurers to claims service providers. 
Using such a system, an insurer may notify the claims service provider of the need to 
scan report documents (e.g. photographs, video image, medical records, etc.) into 
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digital form and then electronically attach these electronic documents to a claim file. 
Such systems identify the need for an attachment, but still require substantial manual 
intervention to actually locate, scan and transmit the desired attachment document. 

Other insurance claims processing systems link claim forms, e.g. a dental claim 
5 form, to specific documentation, such as a dental x-ray. Such a system may be used in 
the specific situation where, for example, a dentist is required to obtain approval from an 
insurance company prior to performing a procedure, and the insurance company wishes 
to view an x-ray as part of its decision making process. 

Other systems link patient information to at least one stored medical record. 
10 Such systems store medical records in an electronic format and associate those records 
with a particular patient. However, they do not enable users to associate needed 
attachments with a particular insurance claim. 

In general, in existing systems, whenever claims require attachments, the claims 
need to be manually reviewed to determine which type of attachment, and which 

15 specific document is required. The document then needs to be located and a copy of 
the document retrieved. This causes a delay in the transmission of the attachment and 
a resultant delay in reimbursement. Attachment retrieval also increases the amount of 
clerical work, such as searching through file cabinets and walking to a different 
department to retrieve the attachments, thereby increasing provider costs. 

20 Furthermore, these attachments are often photocopied, thereby increasing the cost of 
copier operation related to paper and toner expenditures. 

BRIEF SUMMARY OF THE INVENTION 

The inventor has realized that a need exists for a system that provides an 
automated method to identify and retrieve specific documents from a medical 
25 documentation database, and to attach these documents to an insurance claim form. 
While the system should be automated, it should also provide an opportunity for a user 
to intervene and inspect the attachment selection and association process, and to 
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identify additional documentation that may be needed but which has not yet been 
reduced to an electronic form. 

In accordance with principles of the present invention, a system which processes 
claim data related to provision of healthcare to a patient includes the following. An 
5 interface processor receives data related to a claim for provision of a service to a 

particular patient. An attachment processor automatically applies predetermined claim 
submission requirements in processing the claim data to identify: (a) whether an 
attachment document is required to be submitted together with the claim to a payer for 
claim reimbursement; and (b) which particular document is to be provided together with 
10 the claim to said payer for claim reimbursement. A document processor retrieves the 
particular document from storage for provision to said payer for claim reimbursement. 

BRIEF DESCRIPTION OF THE DRAWING 

In the drawing: 

Fig. 1 is a block diagram of the overall claim data processing system according 
15 to the present invention; 

Fig. 2 is a more detailed block diagram of the claim data processing system of 
the present invention; and 

Fig. 3 is a flow chart illustrating the data processing steps performed by the 
system illustrated in Fig. 2. 

20 DETAILED DESCRIPTION OF THE INVENTION 

The document processing system of the present invention is a software 
application designed to meet the needs of different types or groups of end users in an 
insurance claims processing setting. Examples of different groups of users include 
healthcare providers, physicians, dentists, clerical workers and claims administrators. 

25 Fig. 1 is a block diagram of a claim data processing system 1 according to the 

present invention. In Fig. 1, claim data is assembled by the healthcare provider. The 
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claim data is provided to an interface processor 102 which gathers and organizes the 
claim data in electronic form. An attachment processor 104 receives the claim data 
from the interface processor 102 and claim submission requirements from a storage 
device 106. The attachment processor 104 automatically applies the predetermined 
5 claim submission requirements 106 to the claim data to identify whether an attachment 
document is required with the claim to the payer for reimbursement and which particular 
document satisfies the requirement. The attachment may be any type of external 
document, such as (a) a receipt, (b) photograph, (c) chart, (d) invoice, (e) certificate, (f) 
prescription form or any other type of document. The attachment processor 104, thus, 

10 generates a list of attachments required by the claim. The list of attachments is 

supplied to a document processor 108. The list of required attachments is processed 
by the document processor 108 and previously stored images of the documents 
required to be attached to the claim are retrieved from a document repository 110. The 
retrieved documents are matched to the claim and are forwarded to the payer with the 

15 claim. 

In operation, claim data may be assembled by any of a number of known 
systems, including real time entry by healthcare providers, later manual entry by data 
entry clerks, and/or other automated processes. Such claim assembly systems are 
known and any such system, which provides the required capabilities, may be used. 

20 The claim data is then analyzed by the attachment processor 104. The claim 

submission requirements 106 may be represented by a set of rules which are 
processed one at a time. Each rule may analyze one or more fields of claim data to 
determine if the presence of data, absence of data and/or the value(s) of that data 
indicates that an attachment is required, and what document satisfies the requirement. 

25 In general, claim data fields indicate the nature of service provided to the patient. The 
nature of the service may determine whether an attachment is required and what 
document will satisfy that requirement. For example, a rule may associate claim data 
having particular values, indicating provision of a service of a particular nature, with an 
attachment and particular document. 
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More specifically, a payer may require receipts from a medical laboratory before 
reimbursing the healthcare provider for medical tests performed by the laboratory. In 
this example, a field in the claim data contains data that indicates that this claim 
includes a request for reimbursement for laboratory test expenses. A rule in the claim 
5 submission requirements 106 conditions the attachment processor 104 to examine the 
field in the claim data representing the type of expense, and if the value of the data in 
that field indicates that the type of expense is for laboratory tests, the attachment 
processor 104 generates data indicating: (a) that an attachment is required for this 
claim, and (b) that the type of document required is a receipt for the laboratory 

10 expenses. The attachment processor also produces data identifying the specific receipt 
in the document repository 110. This data is supplied to the document processor 108. 
In a similar manner, claim data indicating a request for reimbursement for medical 
services provided to set a broken bone may condition the attachment processor 104 to 
indicate that a copy of one or more X-ray images or photographs is required; a claim for 

15 reimbursement for providing medication may require a copy of a prescription; a claim for 
reimbursement for healthcare services provided by an outside healthcare organization 
may require a copy of a receipt; and so forth. 

In the illustrated embodiment, the document processor 108 is implemented as a 
document management system. A document management system is a database for 

20 documents. Documents are kept in a document repository 1 10 in electronic form, e.g. 
word processing, spreadsheet, images or any other appropriate file format for 
documents. Records are kept for each document in the document repository 110 which 
include data fields used to identify, among other things, where the document is stored in 
the document repository 110, the date and time of the document, a set of keywords 

25 used to classify the document, which parties are related to the document (such as the 
patient, doctor, outside provider in the case of a medical testing laboratory) and other 
important information. These records may be searched by users and used in locating 
documents in the document repository 110. The document management system also 
includes the capability of automatically locating and retrieving documents from the 

30 document repository in response to automated requests. In the illustrated embodiment, 
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the document processor 1 08 uses the data from the attachment processor 1 04 
automatically to locate the required attachment documents in the document repository 
1 10, to retrieve the document and to forward the electronic file representing that 
document to the payer. Such document management systems are known and any such 
5 systems, which provide the required capabilities, may be used. 

Fig. 2 is a more detailed block diagram of a claim data processing system and 
Fig. 3 is a flowchart illustrating the operation of the system illustrated in Fig. 1. These 
two figures are referred to simultaneously in the following description. As seen in Fig. 
2, the claim data processing system 1 is seen to include an interface processor 2 for 

10 receiving raw claim data. This data may contain information identifying the patient, his 
insurance policy, services performed for the patient by the healthcare provider and the 
costs associated with those services. Referring to Fig. 3, regardless of the nature of 
the claim data 2, the system 1 begins at step 28 when the healthcare or other service 
provider performs some service that is reimbursable by a payer 20. The claim data 2 is 

15 produced at step 29 by a compatible claim data processor or external data generation 
system as is known. 

The claim data 2 is sent via path 4 to a rules engine 3 at step 30, either as a 
batch file residing in a predetermined storage or memory location, or in response to a 
direct call by the rules engine 3 through a dedicated rules engine application 

20 programming interface (API). The rules engine 3 has access to the claim submission 
requirements 106 for the payers to which claims are sent by this healthcare provider. 
The claim submission requirements 106 are in the form of a set of rules to be applied to 
the claim data. At step 31 the rules engine 3 identifies the subset of the rules that are 
applicable to the specific payer 20 who is expected to reimburse the claim currently 

25 being processed, and at step 32 applies this subset of rules to the claim data. 

Application of these rules permit the rules engine 3 to determine, at step 33, if the claim 
appears to be valid, that is, if required data is present and if that data has values 
appropriate for the claim. If not, the process returns to step 29 in search of the required 
raw claim data that is missing or invalid. 
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As described above with respect to Fig. 1, the submission requirements rules 
106 also include rules that identify whether an attachment is required. If the claim is 
valid, a determination of whether an attachment is required is made at step 34 by 
applying those submission requirements rules 106. If no attachment is required, the 
5 claim may be generated immediately at step 35. If an attachment is required, the rules 
engine 3 may further generate information 5 for identifying the document that the 
particular payer 20 requires as an attachment based on rules relating to diagnosis, 
procedure, charge information and/or other payer 20 requested claim data 6 contained 
in the claim. 

The payer 20 requested claim data 6 and any attachment information 5 that is 
generated is forwarded to a software subroutine called the attachment processor 7. At 
step 37, the attachment processor 7 operates to determine which document or 
documents, are required to be attached to the claim. In cases where several versions 
of a document exist, the attachment processor 7 determines which version of the 
document is required. If attachment information 5 is present, the attachment processor 
7 scans this data to identify which documents are required. If there is no attachment 
information 5, the attachment identifier 7 processes the claim data 6 to identify what 
documents are required. In this case, the attachment processor 7 processes the claim 
data 6 to derive information including at least one of (a) diagnosis information, (b) 
medical procedure information, (c) charge information, and/or other such information 
related to the claim, and employs the derived information to identify which documents 
are required to be submitted with the claim to a payer for claim reimbursement. 

At step 42 an inquiry is made as to whether the identified documents are to be 
retrieved manually or automatically. The direction to retrieve attachment documents 
25 automatically or manually may be made by asking a system user for each claim, or may 
be set to a desired default setting. Alternatively, a check may be made to determine if 
the required document is in the document management system. If so, then automatic 
document retrieval may be specified. If not, then manual document retrieval is 
specified. 
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If the attachments are to be retrieved manually, a clerk intervenes and obtains 
the desired documents at step 43. In this case, the clerk manually accesses the 
document processor system 8, which may be implemented as a document management 
system, to locate the required documents. If documents are not in the document 
5 processor system 8, the clerk enters them into the document processor system 8. If the 
documents do not exist in any form, the. clerk generates them and enters them in the 
document management system 8. 

If the attachments are to be retrieved automatically, at step 42 the attachment 
processor 7 communicates document description information via path 15 to the 

10 document processor system 8 in order to automatically locate each document or the 
desired version of each document in the document repository 11. If the desired 
document is found in the document repository 1 1 the document management system 8 
returns information specifying the location of the document to the attachment processor 
7. The attachment processor 7 then updates, at step 41, a claims-to-attachments map 

15 9 which correlates or associates the current claim with the location of each of the 
documents required to be attached to the claim. In the illustrated embodiment, the 
claims-to-attachments map 9 contains a record for each identified document containing, 
among other things, data representing the location of the document and the claim to 
which that document is attached. If there is any ambiguity as to which document is to 

20 be attached to the claim, this ambiguity is noted in another data field in the appropriate 
record in the claims-to-attachment map 9. Handling of ambiguously identified 
documents is described below. 

If the required document is not found in the document repository 1 1 by the 
document processor system 8, or if the attachment processor 7 determines that an 

25 attachment containing more data is required, the attachment processor 7 invokes the 
attachment builder 10 at step 40. The attachment builder 10 can communicate with a 
clinical data repository 12A, a laboratory results repository 12B and/or an electronic 
patient record 12C in order to gather the appropriate information needed to dynamically 
construct a document representing the required attachment. The dynamically 

30 constructed document is automatically stored in the document processor system 8 via 
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path 14, and data representing the location of the dynamically constructed document is 
returned to the attachment processor 7 via path 15. The attachment processor 7 
updates the claims-to-attachments map 9 with this data, as described above with 
respect to documents already in the document processor system 8. 

5 For each claim, the attachment processor 7 transmits document location 

representative data from the claim-to-attachments map 9 to an attachment formatter 
and transmitter subroutine 16 via path 17 for the attachments related to that particular 
claim. The attachment formatter and transmitter subroutines then retrieves the 
identified documents from the document management system 8. If necessary, the 
10 attachment formatter and transmitter subroutine 16 formats the documents as 
appropriate according to the specifications of the payer 20. 

In those cases where a clerk manually retrieves attachment documents (step 43) 
or where the claims-to-attachments map 9 indicates no ambiguity as to which 
documents are required and available, the documents are ready to send to the payer 
15 20. Configuration settings specifying the method transmission of the claim and 

attachments to the payer 20 are set via a user interface and database 23 associated 
with the attachment formatter and transmitter 16. For example, claims and attachments 
may be sent to the payer 20 electronically, on paper, or a combination of these 
methods, such as by facsimile. 

20 When the system 1 is configured for automatic electronic data transmission, the 

locations of the attachment documents for the claim being transmitted are retrieved from 
the claims-to-attachment map 9 and provided to the attachment formatter and 
transmitter 16. The necessary document(s) are then retrieved in electronic form from 
the document repository 1 1 by the document processor 8, and are formatted for 

25 transmission to the payer 20 by the attachment formatter and transmitter 16. The claim 
and attachments are prepared for transmission by the user interface and database 23. 

The claim and attachments may be forwarded electronically to the payer 20 by 
employing any desired transmission method, such as facsimile 18A via phone lines, or 
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by electronic data network connection 19, such as by secure electronic mail, by a 
transaction standard compatible communication, or by any other internet compatible 
communication method that meets the needs of the particular healthcare provider and 
payer 20. When data network communications 19 is used, the electronic attachment 
5 documents may be encrypted before transmission, to ensure they are unreadable 
except to authorized receivers. In addition, when electronic mail 19 is used for claim 
and attachment transmission, secure enveloping technology is preferably employed 
prior to or during the transmission to ensure that only the intended recipient 20 can 
access the data. The attachment formatter and transmitter 16 may control the 
10 transmission, or it may use an intermediary, including the document management 

system 8, to perform the transmission. It is also possible to simply print the documents 
(and claim) on a printer 18B and forward them to the payer 20 via standard mail, as 
indicated by a dashed line in Fig. 2. 

If the claims-to-attachments map 9 indicates an ambiguity in one or more of the 
15 attachment documents required for a particular claim, or if the system 1 is configured to 
review the attachments, the attachment formatter and transmitter 16 makes an entry in 
the review queue 21 instead of transmitting the attachments to the payer 20 via the user 
interface and database 23. This entry indicates that a claim and attachments require 
human review. This entry contains data which identifies the claim, the claim data and 
20 the data representing the attachments, including data indicating any ambiguously 

identified document. A user interface for attachment review 24 allows a reviewer to see 
any entries which exist in the review queue 21 , to select a claim in the queue to review, 
and to review the claim data and attachments related to the selected entry. The 
reviewer may approve the transmission of the attachments as they are presented, or 
25 may manually choose other attachments for transmission via the document 

management system 8. If the reviewer selects different attachments, this information 
may be sent as feedback 22 to the attachment processor 7, which, in turn, updates the 
appropriate entries in the claims-to-attachments map 9. 

When attachment feedback 22 is provided by the user interface for attachment 
30 review 24, the user interface 24 also allows the reviewer to revise such feedback 22 or 
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to manually generate feedback 22. In a similar manner, the payer 20 may provide 
feedback on the accuracy of the attachments which were transmitted to it via path 13. 
Such feedback is supplied to the user interface for attachment review 24. The reviewer 
reviews this feedback and forwards it to the attachment processor 7 via path 22 to 
5 permit improvement of the attachment identification algorithms so that better automatic 
attachment matching can be attained. 

It is also possible for the payer 20 to send a request via path 25 either for further 
information in the form of additional attachments, or for required attachments which 
were not included with the claim. In response to such a request an attachment request 

10 processor subroutine 26 invokes the attachment processor 7 via path 27, to locate 
and/or generate any necessary claim and attachment information, and to forward that 
information to the payer 20, in the manner described above. Attachment requests from 
the payer 20 may also be sent to the attachment review user interface 24 via path 13, 
which may be used as described above to optimize the operation of the attachment 

15 processor 7. 

The present invention has been described above in relation to a system for 
processing claim data related to provision of healthcare services to a patient. However, 
one skilled in the art will understand that this system may be used in any business in 
which services are rendered to a customer, and the service provider must file a claim for 
20 reimbursement which may possibly require predetermined documentation to be 
attached. 



The embodiment of the present invention described above is illustrative and 
exemplary only, and is not the only possible embodiment of the present invention. 
Other embodiments in accordance with principles of the present invention are possible. 



